1. Field of the Invention
Embodiments of the invention relate to security policies within a computing system, and more particularly to a method and system of managing security policies within an information technology (IT) system.
2. Description of the Related Art
Information Technology (IT) systems require the definition and management of security policies. This includes access permissions between different applications or programs, between applications and files, between users and applications and/or files and other access control functionality at various layers of the application or network (e.g., IP packet filters, middleware layer access control, application layer access control, information filtering), Quality of Protection policies for confidentiality and integrity of communication using encryption or secure hash functions, or security policies enforced within the application itself, e.g. at the generation of sets or subsets of data. For example, a Service Oriented Architecture (SOA) is a computer systems architectural style for creating and using business processes, packaged as “services”, throughout their lifecycle. SOA also defines and provisions the information technology (IT) infrastructure to allow different applications or services to exchange data and participate in business processes. These functions are loosely coupled with each other, with the operating systems and programming languages underlying the applications. SOA separates functions into distinct units (i.e., services), which can be distributed over a network and can be combined and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services.
FIG. 1 illustrates a conceptual diagram of an IT system 100 (e.g., a service oriented architecture (SOA) system, a data-centric system, an object-oriented system, a component-based system, a publish-subscribe oriented system, a transaction system, a database system, an information flow system, a workflow based system and a message oriented system, etc.). Reference will now be made to FIG. 1 to explain one example of authorization management in a SOA environment. Accordingly, conventional security or authorization management will now be described with reference of the IT system 100 of FIG. 1.
Referring to FIG. 1, the IT system 100 includes a policy node 105, a plurality of services 110, 115, 120 and 125, and a middleware bus 130. Each of services 110, 115, 120 and 125 are software objects that can operate throughout a distributed computing system. Each of services 110, 115, 120 and 125 can be physically embodied or executed at a single computing device, or alternatively at multiple computing devices throughout a computer network. Further, different services can be identified by one or more service identifiers, such as internet protocol (IP) addresses, object references, URLs or by a combination of a service interface and caller identity.
Communication between different services is mediated in the IT system 100 by the middleware bus 130. The middleware bus 130 is not a physical bus as one would find on a motherboard of a computer. Rather, the middleware bus 130 is computer software that connects software components or applications (i.e., services). The middleware bus 130 can be used to support complex, distributed applications. Structurally, the middleware bus 130 can be implemented by web servers, application servers, component servers, messaging servers and receivers, content management systems, Object Request Brokers, and/or similar tools that support application development and delivery. Middleware is typically used to support modern information technology based on extensible markup language (XML), SOAP, Web services, SOA, CORBA, Data Distribution Services (DDS), Message Oriented Middleware (MOM), transactions middleware etc. The middleware bus 130 sits “in the middle” between application software, such as services 110, 115, 120 and 125. The middleware bus 130 can for example be similar to the middle layer of a three-tier single system architecture, except that the middleware bus 130 can be “stretched” across multiple systems or applications.
Referring to FIG. 1, further connected to the middleware bus 130 is the policy node 105. The policy node 105 provides the middleware bus 130 or the application logic with the rules by which the middleware bus 130 enforces security for accesses between the services 110, 115, 120 and 125. This includes access control, encryption of the communications and logging of relevant events. In an example, the policy node 105 can be implemented as a single computer operated by a system administrator, but can alternatively be implemented in a distributed fashion. In addition to the definition and distribution of the security policy, the policy node 105 also receives and displays policy violations and other relevant events.
FIG. 2 illustrates a conventional security policy definition and enforcement process implemented within the IT system 100 of FIG. 1. Referring to FIG. 2, in 200, a system administrator operating the policy node 105 manually configures a plurality of “low-level” or machine-enforceable rules governing access permissions between services 110, 115, 120 and 125. Typically, the system administrator has a general security policy or concept in mind when configuring the low-level rules, for example the BellLaPadula security model to control information flow between services, role based access control, or a security intent described by a small number of high level rules. The low-level rules thereby become the means by which the general security policy is actually enforced within a particular computer network at all layers of the application stack (e.g. network layer encryption and filtering, middleware layer authorization, application layer authorization). As used herein, a “low-level” rule refers to a machine-enforceable rule, where a machine-enforceable rule is a rule with sufficient specificity to be applied at configuration/deployment time and/or run-time by the middleware bus 130 (e.g., “service 110 can access services 115 and 120, but not service 125”, etc.) or other enforcement entity. For example, aside from the middleware layer, the low-level rules could also be enforced at the application layer, network, as a firewall, etc. Thus, while the example of FIG. 2 shows a middleware enforcement scheme, conventional enforcement schemes can be performed in an alternative fashion.
An example will now be provided wherein enforcement of access permissions, in a discretionary access control (DAC) scheme, is based on (i) a client identification, (ii) a target identification and (iii) an operation or access type identification (e.g., send, receive, etc.). For convenience of explanation, Table 1 (below) is limited to permissions regarding a “send” operation. As an example, the policy is expressed as OpenPMF Policy Definition Language (PDL) access control rules. In a similar manner, the rules could be used in other forms as well, e.g. in XACML.
TABLE 1Rule #1(client.name == 110)&(target.name ==115)&(operation.name == send): allow;Rule #2(client.name == 115)&(target.name ==110)&(operation.name == send): allow;Rule #3(client.name == 115)&(target.name ==120)&(operation.name == send): allow;Rule #4(client.name == 125)&(target.name ==110)&(operation.name == send): allow;Rule #5(client.name == 125)&(target.name ==115)&(operation.name == send): allow;Rule #6(client.name == 125)&(target.name ==120)&(operation.name == send): allow;
Accordingly, Table 1 (above) indicates that service 110 is permitted to send to service 115, service 115 is permitted to send to access services 110 and 120, service 120 has no access permission of other services and service 125 is permitted to send to services 110,115 and 120.
Next, after the system administrator completes the manual configuration of low-level rules in 200, the policy node 105 distributes the low-level rules to the middleware bus 130 on each system and all other involved Policy Enforcement Points and security mechanisms. For example, the low-level rules can be distributed to the middleware bus 130 as a configuration for a “plug-in”, such as in the form of a text-file indicating each service's associated access permissions (e.g., as in Table 1, above) or in any other predefined policy exchange format like XACML or OpenPMF's IDL (OMG Interface Definition Language) interface.
This security enforcement at the middleware bus includes, for example, access control at the sender and receiver of data, both configured by a set of low level rules at each side, and an encryption of communication, configured, for example, by a configuration file.
In 210, service 110 requests permission, from the middleware bus 130, to send to (i.e., write to) service 120. Alternatively, the permission request of 210 can be implicit in the sense that the service 110 merely invokes the service 115 via the middleware bus 130. In 215, the middleware bus 130 determines whether to grant service 110 permission to send to service 120 based on the low-level rules distributed by the policy node 105 in 205. Assuming the low-level rules distributed to the middleware bus 130 are those illustrated in Table 1 (above), and that the absence of permission to send is a lack of send permission, the middleware bus 130 determines to deny service 110 permission to access service 120 and sends a policy violation notification to the policy node 105.
The service 110 then requests permission, from the middleware bus 130, to send to service 115, 220. In 225, the middleware bus 130 determines whether to grant service 110 permission to access service 115 based on the low-level rules distributed by the policy node 105 in 205. Assuming the low-level rules distributed to the middleware bus 130 are those illustrated in Table 1 (above), the middleware bus 130 determines to grant service 110 permission to access service 120. Accordingly, in 230, the service 110 sends information to the service 115. If defined by the policy rules, this sending of information is logged.
In 235, the system administrator determines whether to update the low-level rules previously established in 200. Assuming the system administrator determines the low-level rules governing security policies between services requires updating, the system administrator operating the policy node 105 manually configures a new set of low-level rules, 240, and the policy node 105 distributes the new set of low-level rules to the middleware bus 130, 245 and all other concerned security functionality.
As will be appreciated, the manual configuration of low level rules between services or other receiver/sender entities in an IT system (e.g., based on an SOA framework) can be time-consuming and otherwise burdensome upon the system administrator. In addition, these manually defined rules have a very low level of assurance for correctness. For example, while only four (4) services were illustrated in FIGS. 1 and 2, it is typical for a high number of services to be deployed within actual SOA systems. The number of machine-enforceable rules governing access permissions and other parts of the security policy between the different services rapidly increases as the number of services increases, such that a manual configuration of machine-enforceable rules and configurations becomes increasingly problematic and/or impractical. In addition to the rules governing the business functionality of the system, it is also necessary to define rules controlling the infrastructure of the system, e.g. service deployment, directory services and so on. In agile systems it is also very difficult to maintain the rules, in order to keep the rules consistent with the evolution of the applications themselves. Also, non-SOA systems (e.g., data-centric systems or message oriented) suffer from similar problems in low-level enforcement of high level policies due to the tedious manual configuration of rules.